Modified items

All recently modified items, latest first.

zope.app.applicationcontrol-3.5.10-2.lbn13.noarch: Zope applicationcontrol

zope.app.apidoc-3.7.5-2.lbn13.noarch: API Documentation and Component Inspection for Zope 3

zope.annotation-3.5.0-4.lbn13.noarch: This package provides a mechanism to store additional information about objects without need to modify object class. Annotation factories -------------------- There is more to document about annotations, but we'll just sketch out a scenario on how to use the annotation factory for now. This is one of the easiest ways to use annotations -- basically you can see them as persistent, writable adapters.

zope-ztk-1.0.8-1.lbn13.noarch: The Zope Toolkit is a set of libraries maintained by the Zope project for building web applications, web frameworks and application servers.

zope-zopeapp-1.0.8-1.lbn13.noarch: The Zope Application Toolkit - transition support should help existing applications to move to the Zope Toolkit.

zope-zodbupdate-0.5-2.lbn13.noarch: Update ZODB class references for moved or renamed classes.

zope-zodbshootout-0.5-1.lbn13.noarch: This application measures and compares the performance of various ZODB storages and configurations. It is derived from the RelStorage speedtest script, but this version allows arbitrary storage types and configurations, provides more measurements, and produces numbers that are easier to interpret. Running zodbshootout The zodbshootout script accepts the name of a database configuration file. The configuration file contains a list of databases to test, in ZConfig format. The script deletes all data from each of the databases, then writes and reads the databases while taking measurements. Finally, the script produces a tabular summary of objects written or read per second in each configuration. zodbshootout uses the names of the databases defined in the configuration file as the table column names. Warning: Again, zodbshootout deletes all data from all databases specified in the configuration file. Do not configure it to open production databases! The zodbshootout script accepts the following options. * -n (--object-counts) specifies how many persistent objects to write or read per transaction. The default is 1000. An interesting value to use is 1, causing the test to primarily measure the speed of opening connections and committing transactions. * -c (--concurrency) specifies how many tests to run in parallel. The default is 2. Each of the concurrent tests runs in a separate process to prevent contention over the CPython global interpreter lock. In single-host configurations, the performance measurements should increase with the concurrency level, up to the number of CPU cores in the computer. In more complex configurations, performance will be limited by other factors such as network latency. * -p (--profile) enables the Python profiler while running the tests and outputs a profile for each test in the specified directory. Note that the profiler typically reduces the database speed by a lot. This option is intended to help developers isolate performance bottlenecks. You should write a configuration file that models your intended database and network configuration. Running zodbshootout may reveal configuration optimizations that would significantly increase your application's performance. Interpreting the Results The table below shows typical output of running zodbshootout with etc/sample.conf on a dual core, 2.1 GHz laptop: "Transaction", postgresql, mysql, mysql_mc, zeo_fs "Add 1000 Objects", 6529, 10027, 9248, 5212 "Update 1000 Objects", 6754, 9012, 8064, 4393 "Read 1000 Warm Objects", 4969, 6147, 21683, 1960 "Read 1000 Cold Objects", 5041, 10554, 5095, 1920 "Read 1000 Hot Objects", 38132, 37286, 37826, 37723 "Read 1000 Steamin' Objects", 4591465, 4366792, 3339414, 4534382 zodbshootout runs six kinds of tests for each database. For each test, zodbshootout instructs all processes to perform similar transactions concurrently, computes the average duration of the concurrent transactions, takes the fastest timing of three test runs, and derives how many objects per second the database is capable of writing or reading under the given conditions. zodbshootout runs these tests: * Add objects zodbshootout begins a transaction, adds the specified number of persistent objects to a PersistentMapping, and commits the transaction. In the sample output above, MySQL was able to add 10027 objects per second to the database, almost twice as fast as ZEO, which was limited to 5212 objects per second. Also, with memcached support enabled, MySQL write performance took a small hit due to the time spent storing objects in memcached. * Update objects In the same process, without clearing any caches, zodbshootout makes a simple change to each of the objects just added and commits the transaction. The sample output above shows that MySQL and ZEO typically take a little longer to update objects than to add new objects, while PostgreSQL is faster at updating objects in this case. The sample tests only history-preserving databases; you may see different results with history-free databases. * Read warm objects In a different process, without clearing any caches, zodbshootout reads all of the objects just added. This test favors databases that use either a persistent cache or a cache shared by multiple processes (such as memcached). In the sample output above, this test with MySQL and memcached runs more than ten times faster than ZEO without a persistent cache. (See fs-sample.conf for a test configuration that includes a ZEO persistent cache.) * Read cold objects In the same process as was used for reading warm objects, zodbshootout clears all ZODB caches (the pickle cache, the ZEO cache, and/or memcached) then reads all of the objects written by the update test. This test favors databases that read objects quickly, independently of caching. The sample output above shows that cold read time is currently a significant ZEO weakness. * Read hot objects In the same process as was used for reading cold objects, zodbshootout clears the in-memory ZODB caches (the pickle cache), but leaves the other caches intact, then reads all of the objects written by the update test. This test favors databases that have a process-specific cache. In the sample output above, all of the databases have that type of cache. * Read steamin' objects In the same process as was used for reading hot objects, zodbshootout once again reads all of the objects written by the update test. This test favors databases that take advantage of the ZODB pickle cache. As can be seen from the sample output above, accessing an object from the ZODB pickle cache is around 100 times faster than any operation that requires network access or unpickling.

zope-zodbcode-3.4.0-2.lbn13.noarch: Allows Python code to live in the ZODB

zope-zktools-0.2.1-1.lbn13.noarch: zktools is a package of tools implementing higher level constructs using Apache Zookeeper. It currently provides: Configuration - Zookeeper Configuration Helpers to store and load configuration information stored in Zookeeper nodes. Locks - A Zookeeper lock with support for non-blocking acquire, modeled on Python's Lock objects that also includes a Revocable Shared Locks with Freaking Laser Beams described in the Zookeeper Recipe's.

zope-zeo-2.13.22-1.lbn13.x86_64: This package contains the ZEO server and necessary startups

zope-zdaemon-2.0.7-2.lbn13.noarch: zdaemon is a Python package which provides APIs for managing applications run as daemons. Its principal use to date has been to manage the application server and storage server daemons for Zope / ZEO, although it is not limited to running Python-based applications (for instance, it has been used to manage the 'spread' daemon).

zope-zc.zrs-2.4.4-1.lbn13.noarch: secondary storages will automatically replicate data from the primary storage. Replication is superior to back-ups because as long as secondaries are running, secondary data is kept updated. In the event of a failure of a primary storage, just reconfigure a secondary to be the primary, and it can begin handling application requests. Features Primary/secondary replication Support for read-only secondary storages Service registration and discovery with ZooKeeper

zope-zc.zkzopeserver-1.3.2-1.lbn13.noarch: zc.zkzopeserver provides a wrapper for the zope.server WSGI runner that registers with ZooKeeper. By registering with ZooKeeper, you can let the operating system assign ports and have clients find your server by looking in ZooKeeper.

zope-zc.zkzeo-0.3.2-1.lbn13.noarch: Managing addresses, and especially ports is a drag. ZooKeeper can be used as a service registry. Servers can register themselves and clients can find services there. The zc.zkzeo package provides support for registering ZEO servers and a ZEO client storage that gets addresses from ZooKeeper.

zope-zc.zk-1.2.0-1.lbn13.noarch: The zc.zk package provides some high-level interfaces to the low-level zookeeper extension. It's not complete, in that it doesn't try, at this time, to be a complete high-level interface. Rather, it provides facilities we need to use ZooKeeper to connect services: ZODB database clients and servers HTTP-based clients and services Load balancers and HTTP application servers The current (initial) use cases are: Register a server providing a service. Get the addresses of servers providing a service. Get and set service configuration data. Model system architecture as a tree.

zope-zc.z3monitor-0.8.0-1.lbn13.noarch: The Zope 3 monitor server is a server that runs in a Zope 3 process and that provides a command-line interface to request various bits of information. It is based on zc.monitor, which is itself based on zc.ngi, so we can use the zc.ngi testing infrastructure to demonstrate it. This package provides several Zope 3 and ZODB monitoring and introspection tools that work within the zc.monitor server. These are demonstrated below. Please see the zc.monitor documentation for details on how the server works. This package also supports starting a monitor using ZConfig, and provides a default configure.zcml for registering plugins. The ZConfig setup is not demonstrated in this documentation, but the usage is simple.

zope-zc.twist-1.3.1-2.lbn13.x86_64: Twist: Talking to the ZODB in Twisted Reactor Calls The twist package contains a few functions and classes, but primarily a helper for having a deferred call on a callable persistent object, or on a method on a persistent object. This lets you have a Twisted reactor call or a Twisted deferred callback affect the ZODB. Everything can be done within the main thread, so it can be full-bore Twisted usage, without threads. There are a few important "gotchas": see the Gotchas section below for details. The main API is Partial. You can pass it a callable persistent object, a method of a persistent object, or a normal non-persistent callable, and any arguments or keyword arguments of the same sort. DO NOT use non-persistent data structures (such as lists) of persistent objects with a database connection as arguments. This is your responsibility. If nothing is persistent, the partial will not bother to get a connection, and will behave normally.

zope-zc.thread-0.1.0-1.lbn13.noarch: The thread-creation API provided by the Python threading module is annoying. :) This package provides a very simple thread-creation API that: Makes threads daemonic and allows daemonicity to be passed to the constructor. For example: zc.thread.Thread(mythreadfunc) Starts a daemonic thread named 'mythreadfunc' running mythreadfunc. Allows threads to be defined via decorators, as in: import zc.thread @zc.thread.Thread def mythread(): ... In the example above, a daemonic thread named mythread is created and started. The thread is also assigned to the variable mythread. You can control whether threads are daemonic and wether they are started by default: import zc.thread @zc.thread.Thread(daemon=False, start=False) def mythread(): ... After a thread finishes, you can get the return value of the target function from the thread's value attribute, or, if the function raises an exception, you can get the exception object from the thread's exception attribute. (This feature was inspired by the same feature in gevent greenlets.) There's also a Process constructor/decorator that works like Thread, but with multi-processing processes, and without the value and exception attributes.

zope-zc.testbrowser-1.0.0a5-3.lbn13.noarch: Programmable web browser for functional black-box testing of web applications

zope-zc.sourcefactory-0.7.0-2.lbn13.noarch: An easy way to create custom Zope 3 sources.

« Previous 20 items Next 20 items » 1 ... 2278 2279 2280 2281 2282 2283 2284 ... 2359


	Copyright © 2000-2024 Corporation of Balclutha Inc. All rights reserved.

Sections

Modified items